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1.0 INTRODUCTION 


1.0 __ INTRODUCTION 


In contrast to corporate implications of "releases™,s an SES 
Release is a process by which SES Tools are made "available" 
for company internal use with support. In the presentation 
that follows, any reference to “release*® should be interpreted 
in this manner. Definitions of other terms used throughout 
this document are tabulated in Appendix Ae 


The objectives of the SES Release Process are: 


> To provide a timely availability of tools with a built in 
mechanism that allows for rapid repair of deficiencies. 


> To insure that uniform and dependabie procedures are used 
to facilitate tool releases. 


> Te tabulate the Tool Catalog file history in order to 

. identify and recali any release version of these tools and 
to insure the integrity of the toots made availabie 
subject to the COMSOURCE Archive Policies. 


The intent of this Retease Procedures Document is to 
incorporate the purposes of the Release (stated above) into an 
organized program that insures consistency in the building and 
reteasing of SES Toois. 


This document is divided into four main parts. The first part 
deals with the general release process as a whole. The second 
and third parts discuss the rote of the Release Manager and 
the Too! Submitters respectively. The tast part addresses 
various aspects of the release: scheduless catalog managements 
and terminologye 
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200 __ THE RELEASE PROCESSES _IN_ GENERAL 


201 BASIC RESPONSIBILITIES 


A successful retease of a group of tools is dependent upon a 
Systematic and organized execution of the release process 
according to established guidelines. The release process 
guidelines have been defined to facilitate the tasks of the 
Release Manager in co-ordinating the release. A conscious 
effort should be made by all persons involved with the release 
to adhere to these guidelines. 


The fundamental responsibilities of the Release Manager are to 
co-ordinate the Scheduled Release process and manage the Tool 
Catalogs. In co-ordinating the release processs the Release 
Manager will attempt to synchronize within the pre-defined 
schedule the availability of materialss the execution of the 
verification builds and the final release of the new/changed 
tools involved. The section titled “The Scheduled Retease 
Timetable" provides a breakdown of these release process 
tasks. The management of the Tool Catalogs is discussed in 
the section named "Tool! Catalog Management", 


The main role of the Submitter is to construct materiats 
(je. tool PLs»s build procsys and documents) for a tooi's 
release according to the guidlines that this document attempts 
to establish and to submit these materials according to the 
defined timetabje for the refease. 


202 THE RELEASE MANAGER AND TOOL SUBMITTER INTERFACE 


The mode of interaction between the Submitter and the Release 
Manager wills for the most parts consist of the exchange of 
memoss notess listingss and documentation. Memos and notes 
will usually be sent to indicate either the availability of 
tool materials for the Release Manager or the status of 
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certain release process tasks being performed by the Release 
Manager. All such memos and notes should be clears concises 
and complete to eliminate any need for additional 
communication on the matter at hand. 


203 RELEASE TYPES 


Releases are designated by number and are usually scheduted to 
occur at six months intervats. (For more specific dates refer 
to the SES PERT.) The interval within which the release 
activities are performed is referred to as the Release Period 
and designates that segment of time in which specific SES 
projects are scheduled for compietion and in which the 
official release process of the developed tools takes place.» 
This also provides a definite reference point by which the 
availability of those tools may be expected. 


Within any given six month durations there are only three 
types of releases that are conducted by the Release Manager: 


Scheduled Release 
Pre-Release 
Critical PSR Release 


A Scheduled Release is that type of reftease which is performed 
during a designated Release Period. Since any number of tools 
are siated for reiease at this times, the release process 
follows a definite timetab!e covering approximately one 
man-month. The term "scheduled" has two implications here: 
that the point in time of a release has been pre-determined, 
and that the activities leading to this point have atso been 
specifically taid out on a timetabfe. The intention of the 
scheduling is to facilitate the execution of each step in the 
release process for each tool submitted. Any tool that is 
scheduled for release must be in the pre-release at least ten 
days prior to Release Day (i.ee» Day 10 or the Pre-Release 
Cut-Off Day). 


A Pre-Release is designed to accommodate those situations in 
which a tool is made available in the interim between release 
intervals. The main reason for this type of release is to 
allow projects to release code with new features or minor bug 
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2e3 RELEASE TYPES 


fixes 


on amore timely fashion.» 


Pre-release information will 


be made available to SES Users who have expressed concern over 


the availabitity 


of specific toois. 


Community will receive the information 


when requested 


or the Project Leader. 


tested. If 


problems are 


founds 


directly to the Project Leader. 


The general SES User 
these tools only 


from the Release Managers the Tool Submitters 
Pre-Release Toots are not 
they 


extensively 


should be reported 


A Critical PSR Release occurs when a critical bug is found in 
and a temporary fix file is accepted from 


a current 


release 
the Tool Submitter which is placed in the 


SES Catalog. The 


Submitter must eventually follow through the Scheduled Release 


process in order to make the fix official. 


The basic 


primarily a factor of when the tool 
and for what reason. However, there 
components that further distinguish each type. 


differences 


among the 


table illustrates these differences: 


SCHEDULED RELEASE 


Tool made avaitabie 
aftec the formal 
Release Period 


Tool is built by the 
Release Manager 


TAB biurb required 
and User Handbook 
corrections expected 


Access is default via 
SES procedure calls 


three 


release types is 


is to be made available 


are a few other 
The Following 


BASIC DIFFERENCES IN THE 


RELEASE TYPES 


PRE-RELEASE 


Tool made available 


before the formal 
Release Period 


Tool is built by the 
Tool Submitter or 
Release Manager 


TAB blurb required 


Access is through a 
procedure call from 
the SSS PROCLIB file 


CRITICAL PSR RELEASE 


Tool fix made avaitabie 
immediately 


Tool is buiit by the 
Tool Submitter 


TAB biurb required 


Access is default via 
SES procedure calls 
(SES proc attered) 
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204 RELEASE TASK AREAS 


The activities in the execution of the release of any tool are 
shared between the Retease Manager and the Tool Submitter. In 
the release processs there are four identifiable areas of 
activity: 


> The acquisition of Toot documentation 
> The build and verification of these tools 
> Distribution of released tools 


> Support for released tools 


204.1 DOCUMENTATION REQUIREMENTS 


In the initiation of a releases the first and foremost 
requirement is the submission of documentation that properly 
describes the new tools and/or changes to existing tools. 
Common to all three release types is a document offering a 
summary or "blurb" of the Tool’%s condition or situatione Each 
synopsis will simply consist of TXTCODE source containing a 
titie tine and a paragraph that describes the tool's function 
and/or its effected changes. The collection of all of these 
individual synopses under the title line 
TOGL AVAILABILITY BULLETIN 

and arranged by Tool name in aiphabetical order wili then 
compose the general construction of the Toot Availability 
Bulletin ( or TAB ). 


Ali such "biurbs™ should be sent to the Release Manager before 
the Pre-Release Cut-Off Day as the TAB will be made available 
on-line and also sent out to the general SES Communityat that 
time. 


In the particaular case of a Scheduled Releases material for 
the SES User'ts Handbook should be received before other build 
retated materiais are made availabie. Usuall ys this 
documentation is included on a deck in the Tool#s (main) PL. 
Other documents which may also be part of that PL and that can 
be submitted at this time are: the Tool's External Reference 
Specification (ERS) and the Toot Design Document -—if 
available. 
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The selection and the printing of listings is primarily the 
responsibility of the Submitter. Under normal conditionss any — 
necessary listing for a tool should be generated during the 
execution of the buitd procedure or given to the Release 
Manager before the occurrence of the tool's release. 


The following is a list of required documents --some of which 
may be generated by the Submitter separate from the buiitd 
procedures that are expected during the course of the 
schedufed release process? 


Document Made Available Eor 
External Reference before the Tool is released TOOLDOoC 
Specification 
(ERS) 
SES User Handbook before the build process for —— 
corrections the Tooi is started 


or additions 


Design Document before the Tool is reieased TOOLDOC 
(if applicabie) 


Compiled Tool Source during the build process Racks 
with cross-reference . 
tables and expanded 
common decks 


Load Map during the build process Racks 


All such documentation received from the Submitter will be 
kept in a listing binder for common access by the general SES 
Community. Each tool will be kept in a separate binder and 
placed in an area designated as the "SES Library Area, 
Listings for each too! wilt replace old tistings as they are 
accumulated by the Release Manager. 
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20402 BUILD AND VERIFICATION 


The heart of a the Scheduted Release process is the 
verification build of the tools being released. The series of 
events that occur here is briefly outlined below: 


> The Tool Submitter notifies the Release Manager of the 
readiness of the Tool for build. 


> The Release Manager (or his designate) acquires a copy 
of the Toot Pt and performs the build. 


> When the build has been completeds the Submitter is 
notified» and the resulting build files are made 
available to him for verification. 


> Depending upon the outcome of the testss the Release 
Manager will either accept the Tool for official 
releases or freeze its allow the Submitter to make 
corrective changess and then repeat the buitd and 
verification sequence. 


The Pre-Release and Critical PSR Release do not invoitve as 
much participation on the part of the Release Manager. The 
Submitter wilt perform the tool build and verification from 
his own catalog. When satisfied with the resultss he then 
presents the Tool to the Release Manager for "pre-release". 


20423 TOOL AVAILABILITY 


Tool availability occurs in two stepse In the first steps all 
tools that are scheduted for release are required to be in 
pre-release a minimum of ten working days prior to that 
release. This point in time is referred to as the Pre-Release 
Cut-Off Day (Day 10 of the release schedute). In the second 
step» the tools are formally released. This occurs on the 
fast day of the Release Period referred to as the Release Day 
(Day 0 of the reflease schedule). 


Although there sare many tasks that must be completed before 
the formal release of a tools the single event which 
constitutes the actual release is the alteration of the SES 
PROCLIB file such that any procs associated with a released 
tool have been updated to reference the new version of the 
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tool. Refer to the section titled "The Scheduled Release 
Timetable™ for a further summary of the other tasks that 
preceed this event. 


Howevers in the pre-release of a tools, the procs associated 
with that tool are updated or added to the SSS PROCLIB file 
and referenced by a call in the form ‘ 
SESsSSS$ eprocname 

It should be noted that in any of the three release typess ait 
files associated with the execution of the tool are placed in 
the SES Catatog regardiess of the location of the tool's procs 
{i.e SES PROCLIB or SSS PROCLIB). 


20424 DISTRIBUTION 


The purpose of the distribution is to provide non-focai sites 
with tools in usable form. This implies the transmission of 
only the binary files of the tools and their supporting 
procedures. No information or files needed for building the 
tools is sent. 


Tool distribution in conjunction with the Scheduled Release 
will be performed during the Post-Release Phase activities. 
The timetable for installation at remote sites will depend 
upon site conditions but hopefully would occur as soon as 
possible after the completion of the local release. 


The Release Manager is responsile for transmission of copies 
of the new binaries to the remote sites. Tool installation at 
these sites is the responsibility of the focal SES 
representative at each site. 


20425 TOGL SUPPORT 


Oniy the current version of any tool will be considered for 
support. Took support is implied by the category in which the 
tool is classified: Category Is Category II» or Category III. 


Category_I of support is provided when PSRs» RSMs» and SIEs 
written against a tool are regularly reviewed and action is 
taken to process each item according to the availability of 
resources and criticality. This is normatiy a tool with 
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ongoing development activity. 


“Category II support involves periodic review of the PSRs» 
RSMs» and SIEs written against a tool will prompt action to 
process these items based on criticality and impact on the 
User Community. This is normally a tool with no current 
development activity. Tools in this category may be used for 
some special purpose but should be avoided in the normal build 
process if possibie. 


Category III implies no support. No reported probtftems are 
reviewed or acted upon. This is normally a tool with no 
further development planned and should not be used in any 
phase of a build process.» Tools in this category have usually 
been replaced by new tools that provide the same basic 
capabifities. 


The concept of tool support with respect to the Release 
Manager simply constitutes the management of the Tool Catalogs 
and the Tool Catatiog Notebook as described in the section 
titted "Tool Catalog Management", 
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360 _.THE BUILD PHASE AND RELEATED ITEMS 


To begin any build of a tools, the Release Manager must be 
notified by the Tool Submitter indicating the availability of 
the tool files for build and eventual release. This note can 
be sent to the Release Manager through SES.»MAIL. Basic 
information that should be relayed is the formal name of the 
tool and the Submitter's name and phone extension. Subsequent 
items that should then be addressed are: 


> The Tool PL{s) --— particularly the PL containing the 
Toot Build Document (if applicable to the tool)»s and/or 
the Tool*s build proc(s),. 


> Any special instructions needed to generate the Tool 
Buittdd Documents and/or to acquire the Tool Build Proc. 


> The userits catalog in which the Too! PL is stored. 


> To which user catalog the files resulting from the 
buiid should be made availabite for verification. 


> Who is to be notified when the files are ready for 
verification. 


> Any additional comments concerning the accessing of the 
PL contents» execution of the builds or in sending a 
return notification. 


301 THE TOOL BUILD DOCUMENT 


Because of the complexity of a tool's compositions a Tool 
Build Document (TBD) may be necessary to outline or direct any 
potential builder of that tool in the steps required to 
properly construct that tool. The TBD is usually a TEXTCODED 
document of information and instructions usually kept in 
source form ona deck —--usually named BLODGC—-- in the toot'’s 
main sourc PL. Its contents should clearly tay out the build 
process for the tool. Some of the basic information provided 
by the TBD Cif availabe) is: 
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321 THE TOOL BUILD DOCUMENT 


the formal name of the tools 

specific File reqirements » 

specific tresult’' files of the build process» 
reference to build procs that are available» 

special external file/toolt/product dependencies» and 
listings to be generated. 


VvVVV Vv 


The main purpose of this document is to provide the Release 
Manager with a single source that will explain all he needs to 
know about the building of the tool and the organizing of its 
release.» For tess complex toots»s a buitd proc may be the onty 
"documentation" of the tool's build process. 


In either cases a tool's build proc is usually kept on a deck 
—-ususally named BUILD-- in the main source PL of the tool. 
When several such build procs are necessarys they are usually 
named BLDxxxx where xxxx is used to distinguish each proc in 
the build process. All build procs for  eyery tool are 
expected to have HELP information built into it to indicate 
what too! or part of ae tool is being built ands more 
importantlys what parameters are available with the procs and 
subsequentiy»s, their defautt vaiues. 


322 BUILD PROCEDURE GUIDELINES 


The build procedure consists of a collection of control 
statements that will set the execution of the "build" of the 
tool into motion. Such procedures should be constructed in 
the manner of a structured program where a main procedure 
directs the control of other sub-proceduress fileS» and tools 
that support the overall build. The access rabrication of any 
procedure for the buitd is subject to several gene 
requirements concerning its execute tines naming conventions 
for tocal filess and its retationship to a batch environment. 


Build procedures should use SES procs where possibie and 
should be designed to run either as a batch job or 
interactively. Alsos these procedures should be designed to 
accommodate use by the Tool Submitter in his daily 
operationse 


As many buitds will be performed under a single catalog and 
because many files will be generateds, the following naming 
convention should be used to label permanent files that will 
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be of particular concern to the Release Manager --for examples 
compiled ilistings of too! source. The purpose of this naming 
convention is to facilitate the task of file identification 
and dispersement with respect to the tool to which it is 
associated. The convention is as follows-- 


Ail fites created in the build process pertinent to the tasks 
of the Release Manager will be named in the form: 


xxyyyyy where xx is the two-character tool 
identifier and | 
yyyyy is supplied by the 
Submitter for file name 
uniqueness within the build 
procedure, — 


The names of the files that will later be transferred to the 
Tool Catalogs must be passed as parameters to the build 
procedure. File name substitution will be restricted to this 
classification of files and that the parameter tist will be 
kept as limited as possibie. 


If a build procedure completes normatiys it should create a 
local file containing a dump of the NOS Dayfite. The named 
assigned to this file should be of the form: 

xx yy yOK 


If a build procedure terminates abnormalitys it should create 
and save a file containing a dump of the NOS ODayfile and 
should be of the form: 
xxyyERR 
Local files used as scratch files during the build should use 
UNTQUE CNAME) 


to generate a randoms unique file name. 


A typicat build procedure should have the form of an SES 
procedure file. and can be divided into four basic parts 
“--which are illustrated below: ; 


SAMPLE BUILD PROCEDURE 


le To begin withs, the build proc must have HELP 
Documentation built into it so that a user will have 
some immediate means. of determining what the proc 
does and how it is initiated. Such documentation is 
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constructed as follows? 
BLDUT 


\ IF MODE = HELP THEN 
\ ROUT FA = PRIMOUT 


This procedure wili direct the build 
of the PL CROSS REFERENCE UTILITY. 
The parameters are defined below: 


PARAMETERS DEFAULT DESCRIPTION 


utp! SES1054 the source PL 

utbl SES5SOBF * 

utb2 SES50CO * 

utdl1 SES50C1 ° 

utd2 Py » 

utd3 * ° 

pr no print print all listings 
\ ROUTEND PRIMCQUT 
\ STOP 
\ IFEND 


2e The next section of the proc usually establishes 

parameter definitionss default values for the 

parameterss and unique names and tabels to be used 
throughout the proc? 


\ PARM KEY = tutp!? NVALS = O2el NAM 

\ PARM KEY = tutbl1? NVALS = O«2el NAM 

\ PARM KEY = tutb2? NVALS = O«.1 NAM 

\ PARM KEY = tutdli!? NVALS = O«-l NAM 

\ PARM KEY = tutd2? NVALS = Oeel NAM 

\ PARM KEY = futd3'! NVALS = O«el NAM 

\ PARM KEY = ‘pr! NVALS = 0 

AP ARMEND 

\ utp = SETVAL ('SES1054'»s notuseds utpl) 
\ utbl = SETVAL C*SESSOBFt'»s notuseds utbl) 
\ utb2 = SETVAL (*SES50CO'» notuseds utb2) 
\ utdl = SETVAL (*®SES5OC1'», notuseds utdl) 
\ utd2 » 

\ utd3 » 

\ compile = 


UNTQUE (NAME) 
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3e The body of the proc consists of the gencompss 
compiless and loads used to generate object code for 
the tool being built. In this portion of the proc 
other items such as printing of listings and maps» 
Saving specified filess etc. are aiso addressed The 
fayout and grouping of commands is left to the 
discretion of the proc writer. A proc body is 
illustrated as follows: 


SESMSG. *** BEGIN THE BUILD 
ACQUIRE( pt =Eutp!&) 

sesegencomp m=zreadsrc b=pi ab=((pascemnsses)) cf=Ec 
sesepascaix i=Ecompile& Jeutllist beigo cc 
seselink170 pasclib Feigo befutbl& izutlimap 
seserewrite i=futbl& o=futbli CT=s M=e 
SRETURN(Ecompilteébstga) 

\ IF DEFPC(PR) THEN 

seseprint (Cutllistsutilmap) 

\ IFEND 

SRETURN(C utiitstsutiimaps&utb1é) 

SESMSG. ** FIRST BINARY COMPLETED 


sesegencomp m=format b=pi 

sesepascaix izcompiie f=utl2ist 

seselink170 pasclib fetgo behutb2& tzuti2map 
seserewrite isEutb2& oz=Eutb2i CT=s M=e 
SRETURN( compiles tigo) 

\ IF DEFP(PR) THEN 

sesePprint (utl2Iistsutil2map) 

\ IFEND 

S$RETURN( utl2istsutl2mapsEutb2é) 

SESMSG. ** SECOND BINARY COMPLETED 


sesegencomp m=sesdirl b=pl cf=&utdl1& 
seserewrite izEutd1& or€utdl&é CT=s Mer 
sesegencomp izsesdir2 beep! cfs&utd2& 
seserewrite i=Eutd2& o=futd2& CT=s Mer 
sesegencomp m=sesdir3 b=pl!l g=f&utd36& 
seserewrite b=Eutd3& o-butd3& CT=#s Mer 
S$RETURN(Eutdlé&s&Eutd2&sEutd3&) 

SESMSG. ** COMPLETED DIRECTORY FILES 


Notice also how SESMSG is used throughout to continuously 
relay the flow of events to the terminal user as each set 
or portion of the command Flow is executed. The use of 
this feature is particularly beneficial to the tool 
builder (i.e. the Release Manager) who is monitoring the 
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build's progress. 


4. The last part of the proc usually conciudes’ the 
build by returning ali unnecessary fites from the 
working space and then constructs a copy of the 
job's dayfile. Usuallys when a proc is run form a 
terminals, the dayfile is retained only as ae local 
file. If an error occurs or the build proc is 
executed in batch modes the dayfile is retained as a 
permanent file. The last portion of the proc may 
look like this: 


SESMSGe >>>>> BLDUT COMPLETED 

sesedayfile find="BEGIN THE BUILD! n=999 o=ut99ok 
EXIT. 

SESMSG. <<<<< BLDOUT ERRDRS ENCOUNTERED 
ses.dayfile find=*BEGIN THE BUILD*® n=999 orutdayf 
seserewrite izutdayf ofut99err 

$RETURN( utdayf) 


Additional examples are inctuded in the sub-section titted: 
"Examples" to further clarify build proc construction. 


363 INITIATION DE _THE BUILD PROCESS 


In generals the Release Manager will perform a build according 
to the directions presented in the build documentation from 
the Tool Submitter. 


Where the actual execution of the buiid may be very simples 
the buik of the work for the Release Manager involves several 
important. preparatory and follow-up activities. These 
activities are keyed off of the Toot Build Document (TBD) 
and/or the HELP-Mode information from the Tool's build 
proc(s). 


To print the TBD,» the Release Manager must process the 
document through the text formatter and print it --either 
focally or at ae printer. With this document certain 
build=-reltated information can be drawn out before the build is 
performed. The Release Manager should be able to identify: 

> Toot PL{s) required for the builds 

> Named File and Numbered File assignmentss and 

> special flle/product/tool dependencies of the build 

procedure. 
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Upon comptetion of the buitd the Release Manager should be 
able to identify From this document: 
> local files resulting from the builds 
> files that are to be saved for verifications 
> files to be printed out from the build procedures and 
> how these files are to be saved. 


The HELP information provided in the build proc can be printed 

at the terminal during build time by stating? 
sesshelp.procname 

This information should be able to explain to the builder 

(Release Manager) all parameter options for the procs their 

consequences (especially when the keyword name is not 

implicitiy clear)» and their default values when applicable. 


Based on the information from the TBD Cif available)» any 
special! instructions on the Submitter's notices and/or the 
HELP information in the Toolt*s build procs the build 
environment can be established and the build execution can 
begine In briefs the series of tasks involved would be as 
follows: . 

> Identify the file requirements of the build procedure. 

{HELP information) 
> See to it that these files are present or will be 
accessible during the build execution. 

Execute the build procedure(s). 
Identify and save the resulting too! files. 
Gather and bind the tool listings printed out. 
Notify the Submitter of the buiid completion. 


VVVYv 


When the build execution has complieteds all files from the 
build are retained until toot verification indicates a 
successful build. If the verification is positives the files 
may be purged from the build catalog. 


The build procedure execution should always produce a 
listing(s) -—-which may be optionally printed with the 
specification of a "print keyword. As is applicables these 
Tistings should be "name coded" according to the established 
conventions in order to distinguish the different phases or 
parts of the tool build-output. (See the sub-section entitled 
"Build Procedure Outline" for an explanation of this naming 


convention.) All listings are to be retrieved from the 
printer and separated according to tool. Listings should not 
be stored aS permanent files once printed. Each set of 


listings for the tool is then bound and placed in the common 
library area at the central site. 


COMPANY PRIVATE 


, 3-8 
COC SOFTWARE ENGINEERING SERVICES 
07725780 
SES Release Process ae es fo nee 
320 THE BUILD PHASE AND RELEATED ITEMS 
303 INITIATION OF THE BUILD PROCESS 


At this points the Submitter is notified that the build is 
complete and that the tool files are available to him for 
verification. Information that is relayed to the Submitter 
usually indicates: 

> the formai name of the tools 
> the fist of tool files resulting From the build that are 


presently availabie in the build catalog for 
. verifications and ' 
> additional comments or informative notes indicating 


deviations from the specified build procedings. 


It is expected that all files in the build catalog will have 
semi~private and read-only/execute-only permissions. No 
general write permissions will be allowed. 


34% VERIFICATION 


The first and foremost purpose of the Release Manager's buiid 
in the release process is to ascertain that the construction 
of the tool was self-contained ~--that iss the build process 
used only materiais provided by the Toot Submitter and/or from 
Standard/supported products available. 

Verification of the results of a tooi's build should determine 
whether or not the tool that was produced is the same as the 
corresponding tool in pre-retease. The verification is 
usually made in the following two forms: file contents 
comparision and/or tool testing. File contents verification 
involves the comparision of contents of the newly built tool 
file(s) and each counter-part in the SES Catalog. the NOS 
command VERIFY is usualiy used to accomplish this. Tool 
testing invotves the actual exercising of the tool from the 
files that were just built. 


The responsibility of file comparison and tool testing ities 
with the Submitter. The testing of the tool itself should 
have been done prior to submitting the tool for retease. Tt 
is expected that specific tests will be developed by the 
Submitter for each tool. No particular restrictions are made 
on test composition and construction by this document or the 
release processes It is left to the Tool Submitter to 
determine the degree and the extent to which he wishes to test 
the tool since only he is accountable for tool performance 
after the official release occurs. Howevers testing should 
cover all pertinent files resulting from that build. 
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The Submitter will inform the Refease Manager whether or not 
the tool was built property by indicating the condition of the 
tool files resuiting from the builds and will make a 
recommendation for aborts postponements or a go-ahead of the 
tool's release. Based on this reports, the Release Manager 
then decides whether to allow the release of that too! or to 
"“recycie"™ the tool into pre-release. 


325 EXAMPLES OF BUILD PROCEDURES 


The following examples are provided to exemplify the build 
procedure guidelines discussed in the previous sub-sections. 
A brief summary precedes each example to describe the 
situation being depicted and/or to point out items of 
interest. 


325¢1 SAMPLE PROCEDURE --- ACQUIRE 


This is an example of the build proc that will Compile and 
link the ACQUIRE Program. Note in particutar how the HELP 
Mode information is taid out. Also» how the default values 
for the parameters are set using SETVAL»s the use of UNIQUE! 
to generate unique names for scratch files (and labels)» and 
the use of SESMSG to indicate the status of the build 
throughout the proce The body of the proc contains a mixture 
of "SES catts' and KCL Commands. The use of the 'R-registers!? 
is emptoyed to aid the proc in determinng error conditions 
otherwise transparent to the proce The use of this feature is 
feft to the discretion of the proc writer and is not a 
necessity when constructing a build proc. 


BLDACQ 


\ If MODE = HELP THEN 
\ ROUT FA = PRIMOUT 


This BUILD procedure compiles and links the ACQUIRE program 
PARAMETER DEFAULT ALLOWABLE VALUE(S) 
pi SES1080 filename (of source PL) 
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plun SESAUX username owner of pi} 
bin SE$5140 Filename (for binary) 
binun . current user username (owner of bin) 
fist LISTING filename (for listing) 
pr no print keyword 

dayf no dayfile keyword 


In additions all of the standard SES batch job parameters are 
available including the dayfile parameter (default is to run 
the proc in LOCAL mode). If the build is successful» the 
dayfile will be left on a tocal file (defauit name is DAYFILE) 
If the build doesn*t work or the proc is run as a batch jobs 
the dayfile will be saved in a permanent file in the current 
user's catalog. 


\ ROUTEND PRIMOUT 

\ STOP 

\ IFEND 

\  PARM KEY = tpjt NVALS = 1 NAM 

\  PARM KEY = tplun? NVALS = 1 STR 

\ PARM KEY = "bint NVALS = 1 NAM 

\ PARM KEY = *binun? NVALS #« 1 STR 

\ PARM KEY = list! NVALS = 1 NAM 

\ PARM KEY = 'pr? NVALS = 0 

\ INCLUDE 'JOBPARM® L=UNIQUE( NAME) LPFN=SESLNAM UN=SESUNAM 
\ PARMEND 

\ INCLUDE "'JOBHDR1* L=UNIQUECNAME) LPFN=SESLNAM UN=SESUNAM 
\ INCLUDE *JQBHDR2* L=UNTIQUE( NAME) LPFN=SESLNAM UN=SESUNAM 
\ pi = SETVAL(*SES1080t, notuseds pl) 

\ plun = SETVAL(*SESAUX', notuseds plun) 

\ bin = SETVAL(*#SES5140', notuseds bin) 

\ binun = SETVALCIUSERs notuseds binun) 

\ list = SETVALC*LISTING*, notuseds List) 

\ compite = UNIQUECNAME) 

\ Igo = UNIQUE( NAME) 

\ tgob = UNIQUE(NAME) 

\ error = UNIQUE( LABEL) 

\ groovy * UNIQUE{(LABEL) 

\ done = UNIQUE(LABEL) 

\ solong = UNIQUE(LABEL) 


SESMSG.* BUILDING ACQUIRE 
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SESs*GENCOMPs M*ACQUIREs CFeEcompile&Ss BzeEplEs UN=Eptunks e-« 
NOMSGs STATUS=EF. 

IFC EFRNE.O) $G60TO(&erroré) | 

SES»COMPASS»s Te&compitefs Le&8list&» B=&lgo&s NOMSG 

$IF(CEFNE.O) $60TO(&erroré) 

SES»GENCOMPs M=MACQUIR»s CFeEcompileis B=EplEs UN=Eplunks .-. 
PASCCMNs NOMSGs STATUS=EF. 

$IFCEFANE.O) $G60TO(Eerroré) | 

SES»PASCALX»s IT=Ecompilefls L=Elist&s LO=Ry B=Elgofs, NOMSG 

S$IFCEF.NE.0)$G60TO(herroré&) 

SES»LINK170» FeGlgo&s BeElgob&s PASCLIBs L=Etist&s LOs 2 
EP=*ACQUIREsSRFL=$» SSDM=$!', . 

SIFCEF.NE.O0)$GO0TO(Eerroré&) 

SES»~REWRITEs I=Gigob&s O=EbinEs UN=Ebinun&s oa 
FAILED="*Eerror&'s LOOPEND="*ferroré&!?, 

$SET(R1=0) 

$GOTO(Egroovysé) 


EXIT. 

ferrorés* 

SESMSG6.- ERROR(S) IN BUILD OF ACQUIRE 
$SET(R1=1) 


Egqroovyf&»s* 

\ IF DEFK(pr) THEN 
$IFCFILECEDist&s ~.NOT.AS)) $60TO(Edoneé&) 
SES.PRINTs FeElist&s NOSHIFTs ID=*ACQUIRE?® 
\ IFEND 


Edoneé »* 
S$RETURNCEcompilebs&Slgobs&igobistbing) 


\ IF DEFK(dayf) THEN 

\ IF jobmode = 'LOCAL* THEN 

SES»DAYFILEs N#9999» FIND="*BUILDING ACQUIRE's OGzEdayfileé 
EDT(Edayfile&s0)D.S3*.S53-1.2D 

$SIF(R12EQ.0) $60TO(Esolongé) 


\ ELSE 
S$DAYFILECEdayfileé) 
\ IFEND 


SRENAME(Ecompileé=Edayfileé) 
SES»REWRITEs IeEcompitefs OeE&dayfilesé 
S$RETURN(Ecompileé) 

\ IFEND 


Esolongsé »* 
S$SET(EF=R1) 
SSET(R1L=ER1E ) 
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3541 SAMPLE PROCEDURE --- ACQUIRE | | 
+ END BUILD ACQUIRE 
30502 SAMPLE PROCEDURE --- UTLITIY LIBRARY 
BLDULIB 


\ IF MODE = HELP THEN 
\ ROUT FA = PRIMOUT 


This BUILD procedure compiles/assembles all of the 
components of the SES Utility Library for PASCAL-X CC programs 
and puts themn a User LiBrary ready for use with the CYBER 


Loader. 

PARAMETER DEFAULT ALLOWABLE VALUE(S) 

pi SES1O9F filename (of source PL) 
plun SESAUX username (owner cof pl) 
ulib SESULIB filename (for tibrary) 
ulibun current user username fowner of ulib) 
list LISTING filename (for listing) 
pr no print keyword 

dayf no dayfile keyword. 


In additions ail of the standard SES batch job parameters are 
available including the dayfile parameter (default is to run the 
proc in LOCAL mode). If the build is successfuls the dayfile will 
be feft on a local file (default name is DAYFILE). If the build 
doesn't work or the proc is run as a batch jobs the dayfile will be 
saved in a permanent file in the current user's catalog. 


\ ROUTEND PRIMOUT 

\ STOP 

\ IFEND 

\ PARM KEY = pit NVALS = 1 NAM 
\ PARM KEY = *plun'! NVALS = 1 STR 
\ PARM KEY = *ulib! | NVALS = 1 NAM 
\ PARM KEY = tulibun' NVALS = i STR 
\  PARM KEY = "list? NVALS = 1 NAM 
\ PARM KEY = "pr? NVALS = 0 

\ PARM KEY = "dayf! NVALS = 0 

\ INCLUDE "JOBPARM*® L=UNIQUE( NAME) LPFN=SESLNAM UN=SESUNAM 
\ PARMEND 
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\ INCLUDE #JQBHDR1* L=UNIQUE( NAME) LPFN=SESLNAM UN=SESUNAM 
\ INCLUDE *PJOBHDR2!' LeUNIQUE( NAME) LPFN=SESLNAM UN®SESUNAM 
\ pl = SETVAL(*SES1LOGF*, notuseds pl) 

\ plun = SETVALC'SESAUXt, notuseds plun) 

\ ulib = SETVAL('SESULIB'»s notuseds ulib) 

\N ulibun = SETVAL(CUSERs notuseds ulibun) 

\ dist = SETVAL(*LISTING'» notuseds list) 

\ compite = UNIQUECNAME) 

\ Igo = UNTQUECNAME) 

\ templib = UNIQUE( NAME) 

\ error z UNIQUET LABEL) 

\ groovy = UNIQUE(LABEL) 

\ done = UNIQUE(LABEL) 

\ solong = UNIQUE(LABEL) 


SESMSG.* BUILDING SES UTILITY LIBRARY 


SES.~GENCOMPs M=(BLNKSTR.~-CVASC64,s5 ZBIICLO.»~ZBIIWEQs ZDIICLO.~.ZDIISTFs 
ZIDICLOQ.»»ZIGIQRYs ZLGICLO.~«ZLGIWEOs ZPRIOQPN~»ZPRIDUT )s a» 
CFerEcompitef&s B=Eptts UN=Eptunks o- 
NOMSG,» STATUS#=EF. 
S$IF(EFNE.O)$60TO(Eerroré) 
SESePRINTIDs ID="*SESULIB/PXTIQ/COMPASS//)DATE%»s OFElisté 
SESeCOMPASS»s Te&compileés L=Etist&s Bekigo&s NOMSG 
SIF(EF.NE.0O) $G0TO(Eerroré) 
SES-~GENCOMPs M=({ZCLIIAP)» e 
CFeEcompile&s BeEpl&s UN=Eplunts ee 
NOMSG»s STATUS=EF. 
S$IF(CEF.NE.O)$G6OTO(Eerroré) 
SESePRINTIDs ID=*SESULIB/SCL/COMPASS//)DATE*» O=Etisté 
SESs»COMPASS»s IzE&compilebs LzElist&s BeElgobs NOMSG 
$IFC(EF.NE.O)SGOTOl(Eerroré) 
SESeGENCOMPs M=(ZCLMANT.eZCLMXFTs ZOSMEND.»»#ZOSMSSA>» ZPMMDATseZPMMTIM)s os 
CF=Ecompile&s B=E&pt&s UN=Eplun&s es 
NOMSG» STATUS=EF. 
S$IF(CEFL.NE.0O) $60TO(Eerroré) 
SES*PRINTIDs ID=*SESULIB/SCL/PASCAL~X//)DATE*%, OF=Elisté 
SESePASCALXs CC» IT#hcompile&s L=e&list&s BefIigo&s, NOMSG 
SIF(EFNE.O)$GOTO(S&erroré) 
SESe¢GENCOMPs M=(ZN7ICIGeeZN7IWNBs ZUTIABTe sZUTISFN) » oe 
CF=Ecompite&s B=Epti£s UN=EptunEs ABR({OPL» LIBRARY) )» «+ 
NOMSGs STATUS#EF. 
SIF(EFNE.0) $60TO(E€erroré) 
SES~PRINTIDs ID=*SESULIB/MISC.~/COMPASS//)DATE*s O=Elisté& 
SES»COMPASS»s I=E&compilefs Leflist&s BzEIlgo&s NOMSG 
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AO DO PO 08 DE 8a PO 8 fa Pere sa OF PE RO TE PE CN OT OE PO HE PA PO O80 HE TE FE 78 90 PE OE OE PE E88 88 PE PE ET ee 


SIF (EF.NE.O)$GOTO(Eerroré&) _ 
SESeGENCDMPs M=(ZN7MAQR«eZN7MRDR»s ZUTMAQReeZUTMW20)s a 
CF=Ecompilels B=Eplits, UN=Eplun&s e» 
NOQMSGs STATUS#EF. 
$IF(EF.NE.0) $60TO(Gerroré) 
SESs*PRINTIDs ID="SESULIB/MISC.~/PASCAL=—X// )DATE*%, O=Elisté 
SES PASCALXs CC» T=Ecompile&s L=Elist&s BzEtgoks NOMSG 
SIF(EFNE.O)$C0TO(Eerroré&) ; 
$LIBGEN(F=EI goksP=Etemplib&sN=SESULIBsNX=1) 
SES-REWRITEs T=Etemplib&is O=bulib&s UN=fulibun€s .- 
FAILED=*&error&'s LOOQPEND="Cerroré&?, 
$SET(R1=0) 
$GOTOC&groovyé&) 


EXIT. 

S&error&s* 

SESMSGe.- ERROR(S) IN BUILD OF SES UTILITY LIBRARY 
$SET(R1=1) 


Egroovyé&»* 

\ IF DEFK (pr) THEN 

$IFC(FILE(&Tist&s.NOT~AS)I$GOTOC(Edones) 

SESsPRINTs FrEdist&s NOSHIFTs ID=*SES/UTILITY/LIBRARY//) DATE? 
\ IFEND 


Edones» * 
S$RETURN(Ecompifels&igoSsEtempilibés&ulibé) 


\ IF DEFK(dayf) THEN 

\ IF jobmode = *'LOCAL! THEN 

SES»DAYFILEs N=99995 FIND="*BUILDING SES UTIL*s O-Edayfilesé 
EDT (Edayfile&s,0)0.85¥*.S3-1.2D 

S$IF(R1LEQ.0) $G60TO(Esol ongé&) 


\ ELSE 
$DAYFILECEdayfileé) 
\ IFEND 


$RENAME (CEcompilef=Edayfilteé) 
SES»REWRITEs T*Ecompile&s GzEdayfileé 
RETURN Ecompileé) 

\ IFEND 


Esolongis* 

SSET(EF2=R1) 

SSET(RI=ERIE) 

* END BUILD SES UTILITY LIBRARY 
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325.23 SAMPLE PROCEDURE ~--- VE LINKER 
BLDLD 
\ IF MODE = HELP THEN 
\ ROUT FA = PRIMOUT 
This procedure compiles the modules for the VE Linker. 
It*s parameters are shown below: 
PARAMETER DEFAULT DEFINITION 
idp! SES106C source PL . 
idol $ES5118 object library containing relocatables 
Idov $ES$5117 relocatable containing the overlay bin 
pr no print when specifieds will print all listing 
\ ROUTEND PRIMOUT 
\ STOP 
\ IFEND 
\ PARM KEY = 4idpi? NVALS = O«21 NAM 
\ PARM KEY = 'tdolt NVALS = O22e1 NAM 
\ PARM KEY = "'tdov'? NVALS = O2el NAM 
\ PARM KEY = Ypr’ NVALS = 0 NAM 
\ PARM KEY = 'dayf!' © NVALS = 0 NAM 
\ PARMEND 


\ Idp! = SETVAL ('ISES106C's notuseds Idpi) 
\ §}dol = SETVAL (*SES5118t» notuseds Idol) 
\ Idov = SETVAL (!ses5117'» notuseds itdov) 


SETTLs 7777. 
RETURNsLISTINGsLGO. 
RETURN»sLDERROR. 
RFl»20000. 


** COMPILE THE LINKER AND ITS OVERLAY SCHEME 
SES.*GENCOMP ZLDMOO0 B=Eldpi& AB=((SESPLXX»sSES)) 
SESsISWL LARGE LO#R LeLINKLST 

SESeGENCOMP ZLDM100 B=Eldpi& AB=((SESPLXX»SES)) 
SESeISWL LO=R L=LINKLST 

SES~*GENCOMP ZLDM200 B=Eddpif AB=((SESPLXX»SES)) 
SES.2ISWL LO=R LeLINKLST 

SESe«GENCOMP ZLDM300 B=Gtdpi& AB=((SESPLXX»sSES)) 
SES-ISWL LO=R L=LINKLST 
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SES*GENCOMP ZLDMSSC B=Eldple AB=((SESPLXXsSES)) 
SES.ISWL LO=R L=ELINKLST 


\ IF DEFP{pr) THEN 
SESePRINT LINKLST 
\ IFEND 


SES*REPULIB GeLGO BeEtdolé NX 
RETURN»LGOs»sLINKLST. 

SES.~GENCOMP ZLDILNK B=Etdpié AB=((SESPLXX»SES)) 
SES»COMPASS L#LINKLST 

SESsGENCOMP ZLDMDUM B=EIdpl& AB=({SESPLXX»sSES)) 
SESeISWL LO=R L=LINKLST 

SESeGENCOMP ZLDIGVL B=E1ldpif AB=((SESPLXX»sSES)) 
SES»COMPASS LeLINKLST 

SES.*REWRITE T=LGO G=&l dové 

\ IF DEFP(pr) THEN 

SES*sPRINT LINKLST 

\ IFEND 

* BLDLD COMPLETED 


EXIT. 

PACK sLINKLST. 

SES.REWRITE T=LINKLST GeLDLIST 

SES»DAYFILE FIND="SETTLs 7777." N=999 O=LDERROR. 
SESsREWRITE I=LDERROR 

* BLDLD ERRORS ENCOUNTERED 
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4.0 __ MISCELLANEOUS NOTES 


4e1 TOOL _MATERTAL ORGANIZATION 


A tool must be comptetely contained on a minimum number of PLs 
{hopefully one). The composition of "this PL™ must consist of 
ali" the tool source code necessary for tool generations 
"ali" the bulld procedures needed to perform the buitds the 
source necessary to produce the documents reaquireds and test 
cases for tool verification. : . 


402 [ODL DEPENDENCIES 


The dependence of one tool on others practically always turns 
out to be much more intricate and complicated than anyone at 
first supposes. However,» it is possible to confine’ the 
dependencies to specific areas in the buitd procedures and 
therefores make it much easier to insure that the proper 
versions of other required tools are used. <A conscious effort 
should be made on the part of the build procedure writer to 
reduce the number of inter-too!l dependencies to as few as 
possible. 


403 CATALOG DEPENDENCIES 


The probtem of moving a tool from one catalog to another or of 
extracting required toofts or files from the proper catalogs 
has long been a difficulty that has forced past release 
managers to constantly modify buiid procedures "on the fiy". 
It is therefore expected that in alf release procedures’ the 
need to acquire files~--other than files that are submitted as 
part of the bulld process--will onty be from the Tool 
Catalogs. In additions such files should be supported tools 
or products. 
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4.3 CATALOG DEPENDENCIES 


404 PSR CORRECTIONS 


PSRs written against the product will be routed to the Tool 
Submitter via the PSR Coordinator. It will be up to the 
Submitter to inform the Release Manager of the situation. 
Arrangements for non-critical corrections should be made to 
coincide with a Scheduled Release. 


Critical corrections are transmitted to the general SES User 
Community according to the following series of steps: 


1 The creation of a substitute tool binary by the 
Submitter. 


2 Give the Release Manager access to the new binary file. 


3 The Retease Manager will place the corrected version of 
tool in the SES Catalog. 


4 The Tool Proc in SES PROCLIB will be adjusted to call the 
new version of the Tool. 


5 The Tool Submitter will provide notification of this new 
version of the tool to the SES User Community through 
SESeINFO. 


During the next Scheduled Releases the Submitter is expected 


to fotiow up with Scheduted Release procedures in order to 
property document the change. 
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500 _ THE SCHEDULED RELEASE TIMETABLE 


It usuaily requires fifteen (15) working days to complete the 
Scheduled Release activities. Projects must submit materiats 
and complete certain tasks by the days indicated in the 
schedule betow -<-or soonerys if desirede 


Although the exact schedule may vary within any given Release 
Periods the following layout indicates the general occurrence 

of events with respect to specific points in the release 
schedule activities. Day 10 marks the first working day of 
the Release Period. Day -5 is the last working day of that 
period. . 


before Day 10 


The Submitter should have all! of the essential coding 
complete and should be confident that the tool will 
execute properly. 


The Submitter should have isolated and documented aii 
the dependencies his tool has on other tools that are 
being comreleased. 


All changes for the SES User's Handbook documentation. 
should be turned into the Release Manager at this 
time. 


The Submitter will supply the Retease Manager with a 
brief description of the new too! or change(s) from the 
old tool for inctusion in the Tool Availability 
Bulletin. 


The Submitter should have completed the writing of a 
tool build document Cif necessary)» and the 
construction of build procedures, 


The ‘Submitter witi inform the Release Manager of the 
availability of the tools for pre-release. 
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Day 10 


Ati toots that will be released will be set-up in the 
pre-release. 


before Day O 


The Retease Manager will make the TAB available to the 
SES User Community. 


The Release Manager will make the newrt\updated ERS 
materials available to the S€S User Community via 
ToOoLDAC. 


The Release Manager wil? have constructed and reviewed 
the SES User Handbooks presented it to OCS for 
distributions, and made it available to the SES User 
Community via TOOLDOC. 


The Release Manager will begin verification buitds of 
the tools and wil! notify the Submitter when the 
completed tool is ready to be verified. (This will be 
an on-going activity up until Day -5.) 

Day O 
The Release Manager will give public access to the new 
tools. 


before Day ~-5 


The Submitter will have completed the verification that 
his tool was built correctly. 


The Release Manager will complete the verification 
buiids on all toots of the release. 


The Retease Manager will have created a set of tapes 


containing SES Tools and have sent them to the 
non~tocal sites. 


tt is important to note that in foltowing any release 
schedules it is expected that all designated tool materials 


COMPANY PRIVATE 


ons 

CDC SOFTWARE ENGINEERING SERVICES 
07/25/80 
SES Release Process | | | pom 


520 THE SCHEDULED RELEASE TIMETABLE 


will be available by the days specified in the schedule. 
Howevers it is acceptable to submit tooi materiais sooner than 
the schedule shows. 
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6.0 _ TOOL CATALOG MANAGEMENT 


601 INIRODUCTION 


The "Tool Catalog” is a collection of SES toots and files and 
actually consists of three cataiogs: the principle catalog 
which is referred to as the SES Catalogs the SESAUX Catalog 
also referred to as the Auxillary Catalogs» and the SSS Catalog 
which is the "pre-release”™ catalogs 


The reason for the multipie catalogs is to provide the Reiease 
Manager with a means to control! the archiving of tool files 
periodically done by COMSOURCE. The SES Catatog contains only 
those Files necessary to execute the current and reteased 
versions of the tools. Since it is inconvenient to have files 
of this nature archiveds the RETAIN proc is periodically 
executed to retain those files in the catalog. The SESAUX 
Catalog contains the remaining SES tool files --such as PLs 
and backup files or those files from previous SES releases. 
The SSS Catalog» by practices holds onty the PROCLIB 
containing the procedures for executing the Pre-Retease 
versions of tcols. 


When newer versions of existng tools are released,» tool files 
from the previous release and currently residing in the SES 
Catafog are transferred to the Auxillary Catalog. The tool 
files now in the Auxillary Catalog then become subject to the 
COMSOURCE archiving policies and thuss tends to the support of 
the release process objective which is to provide for 
reproducibility of any desired version of a tool. 


6.2 CATALOG CONTENTS 


The contents of the SES Catalog and the Auxiltary Catalog are 
subdivided into two basic types --source files and binary 
files. 


COMPANY PRIVATE 


| 6-2 
CDC SOFTWARE ENGINEERING SERVICES 

07/25/80 
SES Release Process De tes | | | | 
6.0 TOOL CATALOG MANAGEMENT 

602 CATALOG CONTENTS 


Files in the Tool Catalogs are assigned unique names by the 
Release Manager to avoid naming. problems and to provide a 
general identification of the file contents. The general form 
of the name is: 


SESnnnn where nnann represents the numbered 
portion of the name. 


The unique names for submitted files allows the Submitter to 
property identify and verify new files prior to releases and 
also ensures that "old™ versions of tools can be retrieved 
from Archive, 


Some files in the SES Catatog wil! have more meaningful names 
fleege PASCLI8B) because they might be accessed explicitly by 
such names rather than through an SES Procse. The contents of 
these files are updated on Retfease Day. However» any 
specialiy named files are still assigned unique names for 
backup and retrieval capabilities of old versions. 


6.3 BASIC RESPONSIBILITIES 


Management of the Tool Catalogs as handled by the Release 
Manager entails the following responsibilities: 


> to assure that the tatest version and/or tevel of any SES 
tool file is atways availables 

> to make older versions and tevels of any SES tool file 
available upon request--this usually implies the 
un-archiving of files» 

> to maintain an updated tist of files in both catalogs, 

> to remove unnecessary files From either catalogs 

> to assure that proper access permission is established on 

ali the Files» 

to assign numbered fite backups to all Named Files» 

to replace files that have “gone bad™s and 

to replace critical PSR corrected files. 


Vvv 


6.4 TOOL CATALOG NOTEBOOK MANAGEMENT 


The Toot Catalog Notebook jis a textcoded record of afl the 
numbered file assignments made to the Tool Catalogs. 
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Management of this notebook simply involves the recording of 
the names assigned when files are requested by Too! 
Submitters. The File name assignments are made according to 
the conventions as described in the previous sub-section 
entitled “Tool Catatog Contents". Entries in this notebook 
are made to the existing hard copy by hand and then 
periodically updated in the on-—tine copy. Single copies of 
the notebook may be sent to remote SES sites when requested». 
but the notebook is not generally made available to SES 
Users. Oniy the Retease Manager is atitowed to enter 
information into the notebook and make file assignments from 
it. Users wishing to know or obtain file assignments have 
access to the notebook hard copy through the Release Manager. 
This notebook always resides in the Release Manager's Office 
and is never circulated or loaned out. 
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A1.0 __APPENDIX_A__TERMINOLOGY 


Tool 


A tool! is ae facitity to aid in producing products with 
minimal expenditure of times labor» and materials. 


Product 


A collection of files made available for company customer 
use {with support). 


Software Tools 


Software tools are defined as the software (or firmware) 
programs that aid in the development of software. 


Software Engineering 
A branch of engineering in the computer industry whose 
function is to plan the processes of manufactures 
developments and integration of software with minimal 
expenditure of times labors and materials. 


Software Engineering Services or 
SES 


A group of people providing software development tools for 
Advanced Systems Development. 


SES Too! 


A software tool developed bys supported bys and/or made 
available through SES. . 


Tool Identifier 
A two-character identifier uniquely assigned to each SES 


tool for identification of files and for tracking PSR 
informations : 
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Tool PL 


A program library containing the too! source codes build 
procedures, documentations and test casese 


Too! Build Document or 

TBD 
A deck on in the Tool PL named "BLDDOC* that usually 
consists of a single page of text identifying the tool and 
describing the requirements necessary to build it. 


Release 


The process by which SES Toots are made “availiable” for 
company internal use {with support). 


Release Period 
The time within which specific SES Projects are scheduled 
for completion and their products are made available to the 
genera! SES User Community. The Release Period consists of 
two parts: a Pre-Release Phase and a Post-Release Phase. 
Pre-Release Phase 


The time in which toots are made available before their 
scheduled release for other projects co-reteasing tools. 


Post-Release Phase 
The time in which the Release Manager completes build 
activities and sends the refeased tools to the remote 
sites. 
PremRelease Cut-Off Day 
The point in the Pre-Refease Phase by which ali tools 
scheduled to be released are placed in pre-release status. 
AlSos referred to as "Day 10". . 
Release Day 
The point in the refease process at which new/revised tools 


are made available to the general SES User Community. Also» 
referred to as “Day OO”. 
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Aborted Release 
A situation occurring before the official release in which 
submitted files have to be modified after tool verification 
discovers a probiem with the tool. 


SES Retease Manager 


The person who acts as the release oe and is in 
charge of maintaining the presence of SES Tools. the SES 
Catalog. 

Submitter 


The person responsibite for the release and maintenance of an 
SES tool. 


Tool Build Procedure 
A sequence of contro! statements and/or control language 
statements that directs the File manipulations necessary to 
construct (build) a tool. 


Tool Cataliogis) 


The collective term used when referring to all of the SES 
Tool catalogs: SES» SSS» SESAUX. 


SES Catalog 
The collection of permanent files consisting of SES Tool 
binaries necessary to execute a bool. The "no-archive"™ bit 
is set for this catatog. 

SESAUX Catalog 
The collection of permanent files consisting of backup files 
and source PLs for SES Toots. This catalog is set to atliow 
for archiving. 

SSS Catalog 
Holds oniy the PROCLIB file which contains the procedures 


necessary to execute Interim and PSR type versions of 
tools. This catalog is set to allow for archiving. 
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SES Users 
A group of peopte who use SES Tools. 


Tool Availability Bulletin or 
TAB 


A bulletin identifying the new/changed toots of a release 
and briefly describes the new tool's operation and function 
or the user level changes made to an old tool. 


Documentation Control System or 
DCS 


The agency used by SES for tool documentation distribution 
within COC. 
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